A. Field of the Invention
This invention relates generally to networks of consumer electronics devices, and in particular to synchronous networks optimized for digital media streams.
B. Nature of the Problemxe2x80x94Interconnecting Consumer Electronics Devices for Distribution of Audio, Video and other Media/Data, as well as Control Information, Throughout a Home or other Environment
The holy grail of the xe2x80x9csmart homexe2x80x9d has long been sought after, but networking of consumer electronics devices has yet to rise from hobbyist status. One of the fundamental obstacles to widespread acceptance of such networks is the difficulty and expense of interconnecting various types of consumer electronics and other devices within a single room, much less throughout an entire home or other environment, such as a hotel or apartment building, or a car, boat or recreational vehicle.
Moreover, even when such devices are interconnected, there remain problems of distributing control information, as well as audio, video and other types of media/data, in a sufficiently flexible manner to permit users to switch sources, record programs, schedule events and perform other advanced tasks without sacrificing the ease of use provided by a simple television and remote control.
Today""s home theater systems, for example, quickly become unwieldy as devices are added (even apart from the xe2x80x9cspaghettixe2x80x9d of cables interconnecting devices), in part because such devices typically do not all xe2x80x9cspeak the same language.xe2x80x9d Users are faced with fix unenviable task of having to xe2x80x9cprogramxe2x80x9d or configure their system to perform even relatively simple tasks, such as turning the system on and off. Anyone who has tried to explain to a spouse, friend or babysitter how to use the xe2x80x9cuniversalxe2x80x9d remote control (e.g., to watch or record a television program or videotape, laserdisc or satellite broadcast) understands the nature and complexity of this problem.
With the advent of digital media and services (e.g., audio CDs, DSS or DVB digital satellite broadcasts and DVD movies) comes an opportunity to address this problem from a more general-purpose system or network perspective. Such a network perspective can be contrasted with existing home theater and home automation systems which interconnect devices with dedicated media-specific cables (audio and video cables, speaker wire, etc.,), and provide a separate control topology (infrared remote controls, X10 control networks, etc.).
In a digital domain, all information (from audio, video and other digital media streams to custom commands and other control information, and even asynchronous network protocols) can be distributed, processed and controlled using the xe2x80x9csame languagexe2x80x9dxe2x80x94i.e., the binary language spoken by virtually all of today""s computer hardware and software, from dedicated hardware state machines to xe2x80x9csmarterxe2x80x9d controllers and general purpose CPU-based devices.
The opportunities provided by a network of devices distributing digital media and control information are enormous. It is far more difficult and expensive, for example, to distribute/route analog audio and video streams to devices throughout a home or other environment, much less process (e.g. record, mix and otherwise modify) particular information along the way, than it is to distribute such information in a digital environment. Moreover, by providing software control over individual xe2x80x9csamplesxe2x80x9d of digital media, significant new functionality can be added to a system that simply was not feasible in an analog domain.
For example, users could decide to record a movie after watching the first 15 minutes, or record a song after hearing it in its entirety. Playing and recording digital media streams can be as simple as reading and writing a disk drive, as will be explained below. Moreover, with a software interface, users easily could select a variety of programs to be recorded (e.g., over the course of a week) without having to worry about switching tapes in the VCR. Additional telephone lines, or even complex PBX functionality, could be integrated into the system, all under software control for even greater flexibility. As will become apparent, the possibilities are virtually endless. The sheer flexibility afforded by digital media cannot be underestimated.
As discussed below, current systems for interconnecting consumer electronics and other devices suffer from a variety of problems, not the least of which is a lack of foresight with respect to the imminent digital revolution or xe2x80x9cconvergence.xe2x80x9d These problems include difficult and expensive cabling schemes, limited network topologies, complex and expensive devices, inadequate media synchronization and a general lack of integration between the means for distributing audio, video and other media, and the means for processing and controlling the information being distributed.
C. Description of Related Art
Current home entertainment systems and home automation networks illustrate many of the fundamental problems discussed above. Home theater systems, for example, effectively are limited to a single room in a house, primarily due to the difficulty and expense of interconnecting devices.
Each source device, such as a satellite receiver, VCR, laserdisc or DVD player, typically is connected, by relatively expensive audio and video cables, to a xe2x80x9ccentralxe2x80x9d preamplifier or other form of switching device, which is also connected to a main television/monitor as well as to one or more power amplifiers, which are in turn connected to various speakers throughout the room by dedicated (and also expensive) speaker cables.
Such a cabling scheme is both expensive and difficult to maintain. Removing a defective VCR from a rack of equipment, for example, often requires reconnecting cables in a new configuration just to enable the rest of the system to function while the VCR is being repaired. Moreover, flexibility is limited, even with relatively high-end preamplifiers. Only a limited number of source devices can be accommodated by any dedicated device interconnection scheme. It often is prohibitively expensive to replace a high-end preamplifier merely because it will not accommodate the latest source device added to the system. Users therefore still may suffer the inconvenience of connecting and disconnecting cables manually to switch sources.
Moreover, even when all devices can be accommodated, the functionality of such home theater systems still remains limited. Recording programs with a VCR, as noted above, remains a mysteriously unattainable objective. As more source devices are added to a home theater system, the desire to record programs becomes greater, as does the difficulty of successfully recording a desired program.
Users frequently must change tapes, as well as figure out how to xe2x80x9cprogramxe2x80x9d a remote control to make the preamplifier, source device and VCR work together to record a program, particularly if someone is watching another program at the same time. Few systems even permit more than one program to be recorded simultaneously.
The difficulty of controlling consumer electronics devices and systems stems from the fact that most devices are not designed to interoperate with one another. User interfaces on universal remote controls are very limited. LCD screens, for example, rarely are used for more than listing a menu of commands. They rarely indicate any dynamic status information (such as which device is selected, which program is being recorded, etc.).
Moreover, universal remote control devices are extremely difficult to operate, and require extensive xe2x80x9cprogrammingxe2x80x9d to perform even simple functions, such as turning the system on and off, which may require a xe2x80x9cprogramxe2x80x9d to send multiple commandsxe2x80x94i.e., one to each device. Even switching from one source to another may require a multiple-command programxe2x80x94e.g., to switch video input sources on the television as well as switch the preamplifier source.
The result is an expensive system that is complex to set up, use and maintain, even in a single room. Multi-room systems are even more rare, due to the expense of dedicated cabling solutions, and the additional inconvenience of distributing control over devices across rooms. If VCRs, CD players and other source devices are physically located in different rooms of a house, the complexity of the xe2x80x9ccentralxe2x80x9d preamplifier, designed for dedicated cabling to all source and destination devices, becomes unwieldy.
As a result, users improvise by providing redundant functionality. Multiple preamplifiers, multiple VCRs, and multiple remote controls (often xe2x80x9cprogrammedxe2x80x9d uniquely for each room) are deployed, not necessarily because multiple devices are needed at any given time, but primarily because the alternative is too complex and expensive to be practical.
It is thus not surprising that such systems still are limited to hobbyists and high-end gadget-oriented users. Current attempts to address the multi-room problemxe2x80x94i.e., xe2x80x9chome automation and multimedia networksxe2x80x9d exhibit a number of fundamental design flaws. For example, virtually all current home automation standards (X10, CEBus, Echelon LONWorks, etc.) emphasize distribution of control information, as opposed to audio, video and other media.
In other words, such systems distribute analog media on one network or wiring infrastructure and digital control information on another separate network. Custom installation of dedicated audio, video and speaker cables throughout a home is required, and often is prohibitively expensive and results in relatively poor quality due to the degradation of analog signals propagating through multiple devices and extremely long cable runs. Home power lines (or infrared or radio frequency broadcast signals) typically are used to form a separate digital control network onto which remote control/sensor devices can be connected.
The quality of such home automation networks is far below audiophile and videophile standards. Analog audio and video signals simply cannot propagate for long distances, and through multiple A/D and D/A converters and other analog processing circuitry, without suffering significant degradation in quality. Transmitting multiple audio/video channels over coaxial cables, power lines or via radio frequency (RF) transmissions, degrades the signals significantly, and results in relatively low-quality audio and video output. transmissions, degrades the signals significantly, and results in relatively low-quality audio and video output.
Although some systems utilize existing unshielded twisted pair (UTP) telephone wiring to carry analog audio and video signals, the analog modulation of source audio and video signals over UTP cables also produces relatively low-quality audio and video output. Moreover, such systems still require custom installation of such UTP cabling, because the parallel nature of existing telephone wiring topologies (discussed in greater detail below) is not compatible with the dedicated cabling schemes discussed above.
As a result, the expense and complexity of such systems increases exponentially compared with single-room home theater systems. Although control over devices is improved (e.g., by a PC or other controller device, operating under software or firmware control), it is still limited, in essence, to the raw commands accepted by individual devices (e.g., by their remote controls).
Home automation networks, as a result of their separation of control and media distribution functionality, do not allow for sufficiently flexible control over streams of audio, video and other media, except at the most basic level of switching from one source to another. The result, as noted above, is a highly complex and expensive system that is difficult to set up, use and maintain.
Existing home automation networks simply are not poised to take advantage of the advent of digital media. Such media continues to be distributed in analog form over a separate network, distinct from the control network that is the primary focus of such home automation networks.
One potential solution to the problems rioted above is to implement a digital computer-based network of the type typically found in business environments for interconnecting personal computers, workstations, servers and printers. Although the recent increase in popularity of the home computer market has led to a great deal of discussion of home networks which merge general-purpose computing functionality with the consumer electronics devices found in home theaters, the solutions offered thus far do not seem to have advanced beyond the proposal stage.
Applying local area network technology (e.g., Ethernet and TCP/IP network protocols) to consumer electronics devices raises a number of problems. Although it appears advantageous to connect consumer electronics devices as generic nodes on a network, existing network protocols are far from optimized for real-time streams of digital audio and video.
Although current xe2x80x9csolutionsxe2x80x9d are vague in nature, they typically fall into one of two categories. The first is analogous to the home automation networks discussed above, in which consumer electronics devices are connected via dedicated audio and video cables, and still transmit analog information along one network, while an Ethernet network, for example, enables home computers and other control devices to control the operation of the consumer electronics devices. The interface between the two networks is unclear, although the solutions offered by X10 and other home automation network standards appear to apply equally to this scenario.
The other alternative implementation is to distribute audio, video and other real-time media streams in digital form. There are a number of obstacles to this scenario, however, not the least of which is the apparent absence of an existing physical and logical infrastructure to carry the digital media streams. Ethernet, for example, is not optimized to carry real-time continuous digital media streams. It is an asynchronous, packet-based protocol that would add significant overhead to digital audio and video samples, which require consistent and timely delivery, as opposed to the ability to xe2x80x9cburstxe2x80x9d packets of information at high speeds on demand.
The direction currently being followed by the computer industry appears to be focused on one high-speed bus protocol in particular, which was designed to enable personal computers to exchange information with peripherals such as disk drives, digital video camcorders and digital televisions. This bus protocol, known as xe2x80x9cFireWirexe2x80x9d (IEEE 1394), was designed more as an information-exchange protocol (to move data quickly between personal computers and peripherals) than as a network protocol optimized for distributing real-time continuous digital media streams among consumer electronics devices, along with control information, throughout a home.
Nevertheless, the momentum behind FireWire as an industry standard suggests that many home computers and consumer electronics devices soon will have built-in FireWire ports. What remains unclear is whether FireWire can solve the interconnection and control problems discussed above. Following is a brief discussion of FireWire, and of certain of its shortcomings in the context of a home network.
FireWire devices are connected by a custom 6-wire cable, with two wires for power and two twisted-pairs for data. Devices can be daisy-chained to allow tree and other acyclic topologies (i.e., no xe2x80x9cloopsxe2x80x9d are allowed). FireWire devices have limited xe2x80x9cplug and playxe2x80x9d and xe2x80x9chot-pluggablexe2x80x9d functionality. In other words, devices can configure themselves automatically upon being powered on, and can be attached and removed from the network without turning off the entire system. Yet, doing so may interrupt (i.e., xe2x80x9crebootxe2x80x9d) the network, and thus interrupt existing digital media streams, as the network reinitializes and reconfigures devices.
On startup, the bus configures itself in three phases: bus initialization tree identification and self-identification. Whenever a new node is connected or disconnected, a signal sends all nodes into an initialization state, whereupon each node resets all topological information in a distributed manner. In other words, each node determines its own connections and passes this information along to its neighboring nodes, and so on throughout the network. One node is selected as the xe2x80x9crootxe2x80x9d node, and a unique physical ID is assigned to each node (though physical IDs are reassigned every time the bus is reconfigured).
FireWire employs two different processes, called xe2x80x9csubactions,xe2x80x9d for distributing data packets among devices attached to the bus. One is asynchronous, while the other is isochronous. As is explained below. FireWire essentially is an asynchronous bus protocol, in that audio, video and other data packets are not distributed among devices at fixed intervals in accordance with a master clock.
Asynchronous subactions begin with an arbitration period to determine which requesting device is granted control of the bus (because only one device can transmit at a time). The winning node transmits certain transaction and other codes (for speed, format, etc.), along with its address and that of destination nodes, and variable-length data. If the packet is not a broadcast packet, there is a brief gap, followed by an acknowledgment from the destination node. Asynchronous subactions are followed by xe2x80x9csubaction gaps,xe2x80x9d which are required due to propagation delays.
Isochronous subactions are similar, but have a simpler arbitration process, a short channel identifier instead of source and destination addresses, no acknowledgment, and shorter gaps between subactions. FireWire uses a relatively slow 8 kHz clock for isochronous transmissions. After all desired isochronous packets have been sent, the bus resumes asynchronous subactions.
FireWire devices are half-duplex. Thus, devices connected to two or more nodes cannot propagate incoming data while transmitting their own data. FireWire devices employ a xe2x80x9cdata-strobe encodingxe2x80x9d scheme (invented by engineers at Inmos, Ltd.xe2x80x94see U.S. Pat. No. 5,341,371), which involves transmitting data on one twisted-pair wire and a strobe signal on the other pair. The strobe signal transitions whenever two consecutive data bits are the same. This technique was believed to result in increased skew tolerance compared to a standard clocked format (such as 4B/5B or 8B/10B and clocked NRZ coding, as explained below in the context of the present invention).
From the above summary of the characteristics of FireWire, it is apparent that there are a number of obstacles to applying FireWire to real-time distribution of digital media streams among consumer electronics devices, particularly in light of its essentially asynchronous and half-duplex nature.
The installation cost of a FireWire network of consumer electronics devices is likely to be quite high. Custom installation of FireWire cables is likely to he required throughout a house, despite the use of twisted-pair cables. No mechanism for compatibility with existing UTP telephone wiring topologies is included in the FireWire specification.
In addition to the high cost of installing FireWire, the cost of FireWire devices themselves is likely to be quite high, due primarily to the asynchronous nature of FireWire. Because data packets are transmitted asynchronously, devices must be able to buffer incoming packets and generate timing information internally (i.e., xe2x80x9ctimestampsxe2x80x9d associated with the data packets), which must be communicated to other devices. Moreover, almost double the audio data is required due to this buffering/timestamping process, resulting in a significant loss of bandwidth. This results in complex and expensive devices, due to the memory, buffers, counters and associated circuitry required to perform such functions. Even a simple FireWire device requires at least a simple processor (CPU) and memory to implement the FireWire protocol stack.
The 8 kHz isochronous cycle simply is too slow for applications requiring CD-quality (44.1 kHz) audio. Were FireWire to increase its isochronous cycle frequency to 44.1 kHz, some of these obstacles might be overcome.
The lack of asynchronous time base also results insignificant clock jitter. The start time of an isochronous packet may be delayed by an asynchronous packet (due to their variable length). To account for this possibility, a delay is encoded in the xe2x80x9ccycle startxe2x80x9d signal, resulting in clock jitter. Moreover, additional jitter results from the variable amount of time between the xe2x80x9ccycle startxe2x80x9d and the actual start of a specific device""s subactions, requiring each device to maintain its own timing register to account for this source of jitter.
There are solutions to these timestamp and clock jitter problems. Yet, they add significant cost and complexity to every device attached to a FireWire bus. As a result, FireWire devices need CPUs just to manage these bus protocol issues. This could be a significant obstacle to acceptance of FireWire for anything beyond relatively high-end computer peripherals and the most expensive consumer electronics devices, such as HDTV or digital camcorders.
For applications requiring real-time delivery of continuous digital media streams, FireWire has additional problems. One significant limitation to FireWire is the total length of the connecting cable, which is limited in the current specification to 4.5 meters (unless extremely expensive fiber optic or other alternative cables are used). This short length is a significant limitation even within a single room used for a typical home theater system; and is prohibitive in the context of a house-wide application, such as a home telephone PBX or multi-room digital audio and video distribution system.
Even if repeaters could be accommodated, such devices would be relatively expensive, and would contribute to FireWire""s 64-device limitation. An asynchronous FireWire router might well become necessary to accommodate additional devices beyond this limit. Such a route would be extremely complex, requiring knowledge of data types to reassemble packets, buffering of variable-length packets, etc. In addition to being expensive, such a router would impose variable-length delays, making it extremely difficult, for example, to synchronize two speakers receiving information from a source device via the router. Each speaker would have to receive and handle timestamps (due to variable delays from other devices, as well as the router), and reassemble data packets, just in order to play 44.1 kHz digital audio samples.
Another problem with FireWire devices in the context of a network of consumer electronics devices is that no mechanism exists to enable such devices to be truly hot-pluggable. The FireWire bus will reset whenever a device is added or removed, resulting in an interruption (however short) to all existing data streams. The FireWire specification contains no provision for a router or other device to isolate a particular device or chain of devices from the rest of the network, such that the FireWire bus need not reset, and thus disrupt, the entire network when a device is added to or removed from this isolated network segment or zone.
The lack of static device IDs also creates problems. Each device must update its topology table whenever the bus is reinitialized e.g., whenever a new device is added or removed, or a device malfunctions. No device therefore can rely on these device IDs remaining constant.
As will become apparent below, certain of the techniques employed in the present invention could be adapted to FireWire buses and associated FireWire peripherals. For example, FireWire peripherals could be adapted for use as a node on a network of the present invention. Moreover, certain of the disadvantages of FireWire noted above could be overcome to some extent by adopting and/or combining with particular aspects of FireWire certain of the techniques discussed below.
For example, static device IDs could be employed to simplify device identification and addressing, as well as the self-configuration processxe2x80x94because a device""s presence could be detected via its static ID. Static IDs also would facilitate the implementation of copy protection, fraud detection and other features that rely on the identification of particular devices. In addition, device-specific information could be stored along with the device ID, such as pointers to external device drivers (as discussed below).
Nevertheless, FireWire remains essentially an asynchronous bus protocol. It simply is not optimized for distributing real-time continuous digital media streams among consumer electronics devices in a network environment. It was designed as a computer peripheral bus, for exchanging data (asynchronously) between computers and peripherals, such as disk drives and digital camcorders.
Unlike FireWire, a truly synchronous network could overcome many of the limitations discussed above. Yet, synchronous network protocols (as discussed below) have not been optimized or adapted for use with consumer electronics devices to enable the distribution of digital media streams in a manner that overcomes the limitations noted above.
TDMA networks, for example, utilize time-division multiplexing, and synchronize all devices to a master clock. Yet, the bandwidth on a TDMA network typically is divided equally among the devices on the network. In other words, if 10 devices are on the network, each device gets {fraction (1/10)}th the network bandwidth, and thus can transmit information only during that channel or xe2x80x9ctime slicexe2x80x9d (e.g., during unit 1 of every 10 units of time).
In the context of transmitting digital media streams, however, certain data streams require more bandwidth than others. Video data, for example, requires more data than audio, though it is sampled less frequently. Yet, TDMA networks assign each device a single channel in which to transmit all of its data. These channels are based simply on the number of devices on the network, and bear no relationship to the bandwidth requirements of the type of data being transmitted. This problem is exacerbated when asynchronously distributed variable bit-rate data, such as MPEG2 compressed video, must also be accommodated. TDMA network technology provides no solution to either of these problems. TDMA devices are left with a single fixed-width channel which is not well suited for accommodating either multiple real-time continuous data types having differing bandwidth requirements, or an asynchronous data type having bandwidth requirements that vary over time.
Even in the context of a ring network, in which data propagates from one device to another around a loop oaring (and is overwritten when a device desires to insert its own data), a device on a TDMA network could transmit information (such as a digital audio sample) anytime during its assigned time slice. Moreover, that time slice might charge whenever a new device is added to or removed from the network. Thus, a device cannot guarantee consistent delivery of particular data, despite the synchronous nature of TDMA.
Ring networks, however, appear to be good candidates for consistently delivering particular data (e.g., a digital audio stream) from one device to another (e.g., from a CD player to a speaker), assuming that such information propagates around the ring at a consistent rate (e.g., synchronously, based upon a master clock). Yet, existing ring networks suffer from many of the same deficiencies discussed above.
Token Ring networks, for example, are asynchronous in nature. Each device transmits data only when it receives the xe2x80x9ctoken,xe2x80x9d which does not occur at fixed intervals of time. Thus, such networks cannot guarantee consistent delivery of real-time continuous digital media streams.
FDDI networks on the surface appear to be synchronous ring networks; yet, they transmit information synchronously only in a point-to-point manner. In other words, the transmitter on one device is synchronized to the receiver on the next device on the ring. Yet, the transmitter and receiver within a device are not synchronized to each other. Information therefore will not always propagate through a device at a consistent rate, due to the difference between the transmit and receive oscillators within a device, among other factors.
FDDI devices compensate for this difference with an xe2x80x9celasticity bufferxe2x80x9d which avoids losing data, but does not guarantee consistent delivery of data. For example, if a device receives data xe2x80x9clate,xe2x80x9d it will transmit that data late. If it receives data xe2x80x9cearly,xe2x80x9d it will place that data in its elasticity buffer, and transmit such data in a FIFO fashion.
Thus, FDDI devices also cannot guarantee consistent delivery of data such as real-time continuous digital media streams. They are optimized for high throughput, but not for consistent, synchronous delivery of data.
D. Resolving the Problem
The above description of home theater systems and home automation networks, and of various existing asynchronous and synchronous network protocols, illustrates many of the obstacles to interconnecting consumer electronics devices for distribution of audio, video and other media (including both real-time continuous digital media streams and asynchronous data), as well as control information, throughout a home or other environment. It also serves to explain why the xe2x80x9csmart homexe2x80x9d has remained such an elusive goal.
Problems such as those discussed above must be resolved before home networks can achieve widespread acceptance. What is needed is a low-cost physical network topology, preferably one that is compatible with the existing physical cabling infrastructure in a home, to avoid the significant barrier to entry of having to rewire an entire home merely to set up a simple network consisting of a few devices. Such a topology should enable devices to be interconnected with relative ease, as contrasted with the difficulty and expense of interconnecting audio and video and other consumer electronics devices within and across rooms of a home using available technologies.
Such a network also should be compatible with existing consumer electronics devices, again to avoid the significant barrier to entry of having to replace all existing devices merely to set up a simple network consisting of a few devices. Moreover, such adapters and other devices preferably should be relatively inexpensive (at least no more expensive than comparable existing devices) in order to encourage consumers to adopt this new technology.
The network should accommodate real-time continuous digital media streams, as well as asynchronous data (and digitize existing analog audio and video) in order to provide the significant benefits and flexibility noted above. To do so, the network must deliver such digital media streams reliably, in order to provide the same level of synchronization as is currently provided by existing analog delivery mechanisms.
To achieve these objectives, one embodiment of the present invention provides a protocol and architecture for a synchronous logical ring network which operates on the existing physical twisted-pair telephone topologies found in most homes today (forming a xe2x80x9clogicalxe2x80x9d ring without requiring in-wall wiring modifications). The logical ring network can even replace the existing analog telephone network in the home. It can accommodate daisy-chained network devices which, because they need not be connected to a junction box in the wall, require neither in-wall nor junction-box wiring modifications. Moreover, virtually any physical topology (star, loop, tree, etc.) throughout a home, office or other environment can be converted, with minor junction-box wiring modifications, into a logical ring network of the present invention.
Information can propagate around this logical ring, reaching every device on each revolution around the network. Network devices are full-duplex, transmitting and receiving information simultaneously.
An arbitration process occurs automatically upon network initialization, and one of the competing devices is elected the network clock device to which all other devices are then synchronized. By synchronizing all network devices to a single reference clock, and providing fixed frames of information propagating around the network at consistent time intervals (44.1 kHz xe2x80x9cframe ratesxe2x80x9d in one embodiment, to enable device synchronization to the CD audio sample rate), the logical ring network ensures that information always will propagate from one device to another at consistent time intervals. In other words, information will propagate consistently around the logical ring network at the frame rate; and the time required for information to propagate between any two particular devices will remain fixed.
Following network initialization (and whenever devices are added or removed), an auto-configuration process configures each network device and determines the network topology. The entire network topology is discerned and made available to interested devices, even though individual devices need not be capable of interpreting such information. Devices can be added and removed in true xe2x80x9cplug and playxe2x80x9d fashion, and will be hot-pluggable if connected anywhere on a chain of devices attached to a xe2x80x9chot-pluggable smart jackxe2x80x9d device.
Most network devices are relatively xe2x80x9cdumbxe2x80x9d and inexpensive, in that they require only simple hardware state machines to accommodate the basic network protocol, and to transmit and/or receive digital media streams. Network devices have unique static device IDs, which simplify device identification and addressing, as well as network initialization, and form the basis for encryption to provide network security, authentication and/or copy protection functionality. Devices also can contain other device-specific information, including device drivers (or pointers to external device drivers) that can be executed on their behalf by xe2x80x9csmartxe2x80x9d CPU-based controllers.
In addition to accommodating adapters that connect existing consumer electronics devices to a logical ring network of the present invention, the network architecture accommodates new xe2x80x9crestructuredxe2x80x9d digital-ready devices that redistribute existing device functionality across the network. For example, by removing MPEG2 decoders from DVD players, the compressed digital information can be distributed/processed throughout the logical ring network before reaching its ultimate destination (e.g., a television attached to or incorporating an MPEG2 decoder).
Information propagates along the logical ring network in fixed-length frames which, in one embodiment, comprise 640 bits of encoded data, transmitted at a raw bit rate of 28.224 MHz. In addition to xe2x80x9cframe headerxe2x80x9d markers that synchronize devices to a master clock, these frames contain two independent streamsxe2x80x94a xe2x80x9cdata streamxe2x80x9d for the distribution of real-time continuous digital media streams, as well as asynchronous data, and a xe2x80x9csystem command streamxe2x80x9d for the distribution of xe2x80x9csystem commands,xe2x80x9d which are used primarily for network initialization and auto-configuration of network devices, as well as basic switching of digital media streams. The system command stream propagates along a xe2x80x9cdefault network pathxe2x80x9d that reaches every network device. The data stream, however, can propagate along any available path, to provide for greater overall network bandwidth (e.g., by adding a switching router device to the network to create alternative data stream paths).
The data stream is divided into distinct xe2x80x9cchannelsxe2x80x9d (the size of each channel being tailored to the bandwidth and sample-rate requirements of a particular media type) which operate by default, and can be reallocated dynamically (in some cases even occupying discontiguous portions of the data stream). In this manner, devices can reliably guarantee consistent delivery of data (e.g., audio samples at the standard CD audio 44.1 kHz rate) having particular bandwidth requirements. Thus, two speakers on the network will receive left and right channel digital audio, respectively, at the xe2x80x9csame timexe2x80x9d (i.e., within one sample time of accuracy), and thus be synchronized to each other (i.e., phase coherent), even if the source device is physically located in another room and/or zone of the network). Phase coherency is a critical factor in high-quality stereo audio systems, as well as multi-channel surround sound systems, such as Dolby AC-3.
The data stream also can contain embedded control information and other asynchronous data, including compressed MPFEG2 video and other variable hit-rate data, as well as asynchronous network protocols, such as I2C, RS232 serial protocols and TCP/IP. Such information is delivered synchronously, however, thereby avoiding collisions. Network devices also can utilize channels of the data stream to send custom commands to one another, including control information, pursuant to virtually any protocol known to such devices.